Most traditional file systems do not support transactional capabilities. Applications need to give better guarantees to the user in terms of maintaining data integrity when unexpected events like power glitches, hard disk errors, etc. occur as they try to save files. In the absence of transactional capabilities, applications employ various schemes to maintain data integrity of files. A common strategy involves writing to a temporary file whenever an update is performed and its contents are saved. On a successful completion of the write and save operation on the temporary file, applications replace the original file with the temporary file. Typically, the files are identified by their names, although most file systems also use one or more additional internal identifiers. The strategy described above, often referred to as safe save, creates an illusion to the user that his/her actions were always directly happening to the original file.
Note, however, that some key data in the original file could be lost as part of replacing the original file with the temporary file. For example, in the case of NTFS (one of the file systems supported by Microsoft Windows operating system) these key data may include creation time, long/short name, object ID, alternate streams, etc. Operating systems may provide one or more APIs to assist users in automatically copying over some of these key data while doing safe save of files. The process of copying over one or more of the attributes (and data in some occasions) from one file to another by the operating system is called Attribute Tunneling. Attribute tunneling typically gets triggered when a file name disappears and reappears in the same directory within a stipulated time. File names can disappear through delete, rename or move operations. And, they can reappear through create, rename or move operations. Sometimes, applications may have to copy more data (e.g., security descriptor) or attributes in addition to what the operating system provides while doing a safe save.
Richer storage systems often provide the ability to associate or attach additional data like sticky notes, annotations, references, pictures, etc. to items including files. These additional data (rich data) can be arbitrary in their number and size. For efficiency, these systems internally tend to associate the rich data with the ID of the item (say, itemID). As part of the safe save operation the temporary file created gets a new ID and subsequently when the original file is replaced with the temporary file, the rich data associated with the ID of the original file fails to get transferred. To the user this manifests as simple loss of data, partial or full, while doing an operation like saving a document.
This type of traditional file saving requires that applications and systems be aware of rich data and how to preserve it. As often is the case, different applications and different systems can be of varying levels of sophistication and age, causing mismatches between how data is saved. Thus, if a system is not expecting rich data, it may not properly transfer it to the changed data. Additionally, the act of transferring the data can also add to the processing burden of a system or application depending on the size and number of data elements associated with the core data.